Hello, 各位 iT 邦幫忙 的粉絲們大家好~~~

這系列文源自這幾年在團隊裡導入 AI Coding 之後，一路踩雷、修正、再踩雷的真實過程。把這些收斂出來的方法整理成文，也許對正在煩惱同樣問題的你會有些幫助。

就當作是一份邊做邊記的工程筆記吧！

本篇是 當 AI 加入團隊：打造可審查、可驗證、會自我改善的 AI 開發工作流 系列文的 EP01。

先講一個大概每個導入過 AI Coding 的團隊都會遇到的場景：

某天，工程師 A 靠著一串很厲害的 Prompt，三兩下就解掉了一個棘手的問題。隔天，工程師 B 遇到類似問題時，完全不知道 A 是怎麼問的、參考了哪些資訊，又是怎麼確認修好的——因為那串 Prompt 只活在 A 的聊天視窗裡，收工後就跟著視窗一起被關掉、被遺忘。

這不是 AI 不夠聰明的問題，是經驗沒有被留下來的問題。

在還沒有導入任何工作流規範之前，我們這個團隊也是這樣：

• 同樣的診斷步驟，每個人各問各的，答案品質時好時壞。
• 同樣的裝置操作與安全提醒，只存在某個人的腦中或私人筆記裡。
• AI 有時候會很有自信地說「已經完成、已經驗證過了」，但實際上根本沒有跑過任何檢查。

於是我們開始想：如果 AI 真的要變成團隊的一份子，那它就不能只是一個「很會回答」的工具，而必須遵循一套團隊共用、可被審查、能持續演進的工作規則——而不是散落在每個人聊天紀錄裡、無法複製的個人經驗。

這就是本系列文對 AIOrchestrations 的這個共用工作流工具箱，最初想解決的問題：讓 AI 的行為變成一份可以被團隊共同擁有、審查與更新的資產，而不是某個人腦中的默契。

接下來的 29 篇，會按照我們實際走過的順序，一步步展開這套工具箱是怎麼長出來的。

那，先從「骨架長什麼樣子」開始講起吧！